Fix to releases on PyPI - #569

As @AkshatRai07 suggested in #568 (comment) perhaps best to first try to see whether this works

best to first try to see whether this works

I thought it'd just require a change in some PyPI settings, but it did require an actual change to the files. Fortunately, we can run workflow again with providing a tag variable now after merging this PR, no need to wait for a tag push. I'll change the release-python.

@scarlehoff if I'm not wrong, release-ekors and release-python too require a fix like cd27bb7, right?

I thought it'd just require a change in some PyPI settings,

tbh, I could've also removed the environment there, but I liked the option of adding the environment best.

release-ekors and release-python too require a fix like cd27bb7, right?

Yes!

I thought it'd just require a change in some PyPI settings, but it did require an actual change to the files. Fortunately, we can run workflow again with providing a tag variable now after merging this PR, no need to wait for a tag push. I'll change the release-python.

good we can bring #561 to good use

release-ekors and release-python too require a fix like cd27bb7, right?

Yes!

Edit: but now I'm not sure how to do it with https://github.com/NNPDF/eko/blob/master/.github/workflows/python-poetry-pypi-with-data.yml tbh

just to make sure one is not relying on the other to act: @AkshatRai07 can you please take care?

Aaaha, it seems Github has already recorded the most relevant information for me. Here is more information:

• step 2: ekore-rs worked: https://pypi.org/project/ekore-rs/ - but it has no description. @AkshatRai07 we can address that here or open a dedicated issue
• step 1: eko failed, because the version was 0.0.0~something since this is what poetry-dynamic-versioning was determining. @AkshatRai07 should we just remove the possibility to specify a custom tag from that workflow? else we need a way to overwrite poetry-dynamic-versioning.
• step 3: eko-rs failed with "400 Non-user identities cannot create new projects. This was probably caused by successfully using a pending publisher but specifying the project name incorrectly (either in the publisher or in your project's metadata). Please ensure that both match. See: https://docs.pypi.org/trusted-publishers/troubleshooting/" - which sounds like a problem in the config at PyPI @scarlehoff ?

only slightly related (and could have been part of #561 🙈 ): we should update some of the actions/* reusable workflows to a newer version, so we don't get warnings about Node deprecation. Again this can go easily into a separate issue.

On second thought ... fixing failing workflows is quite handy for debugging, but it is also quite dangerous, sine you can make up anything ... I'm no longer 100% convinced this is a good idea 🙈

which sounds like a problem in the config at PyPI @scarlehoff ?

Someone the trusted publisher is not there for eko-rs. I am convinced I added it as well but clearly no? Or maybe I added something wrong and it got destroyed on the failure?
In any case I've added it as well (pointing to release-ekors.yml, which I think is correct?)

On second thought ... fixing failing workflows is quite handy for debugging, but it is also quite dangerous, sine you can make up anything ... I'm no longer 100% convinced this is a good idea 🙈

What do you mean?

Someone the trusted publisher is not there for eko-rs. I am convinced I added it as well but clearly no? Or maybe I added something wrong and it got destroyed on the failure? In any case I've added it as well (pointing to release-ekors.yml, which I think is correct?)

It worked: https://pypi.org/project/eko-rs/

On second thought ... fixing failing workflows is quite handy for debugging, but it is also quite dangerous, sine you can make up anything ... I'm no longer 100% convinced this is a good idea 🙈

What do you mean?

it's a classic case of "with great power, comes great responsibility" 🕸️ e.g. here I could now "posthumously" release 0.15.6, which is sane since nothing happened since the true tag. But I could have also added a new feature (now or in the future) and could still call it "0.15.6" although this would be not correct. Should I worry or rely on "we are adults here"?

@AkshatRai07 I was hesitant to label this as gsoc26 before since I was unsure about the timescale and I'm not sure if you worry about having (still) open PRs. Actually, on second thought, it could also be good as sign of active work to have open PRs ...

I see what you mean.
I guess protecting ourselves against our own mistales could be a good idea 😅